1. Field of the Invention
The present invention relates to the field of data communications networks. More particularly, this invention relates to a method and apparatus for limiting the number of virtual private data network (VPN or VPDN) sessions provided to a group of users locally and network-wide in a data communications network
2. The Background
ISPs (Internet Service Providers) and Telcos (telephone companies) (collectively referred to as “Wholesale Providers” or “Wholesalers”) typically offer various forms of retail Internet access to their subscribers. In a typical retail model as shown in FIG. 1, a user will contact a network access server (NAS) either using dial-up telephone lines, digital subscriber lines, ISDN (integrated services digital network) lines, or the like. The NAS interfaces the user with the data communications network. The way this works is that a user, for example, Joe@corpa.com, dials in to a NAS at ISP's Point of Presence (PoP1) on the lnternet. A PPP (point to point protocol) session 12 is raised between NAS1 14, and Joe's terminal 16. An LCP (Link Control Protocol) session is raised between NAS1 and Joe's terminal. At this time the NAS1 generates an AAA authentication request using a protocol such as RADIUS (Remote Authentication Dial-In User Service) to the ISPs AAA (authentication, authorization and accounting) service 20. The AAA service 20 handle Joe's authentication (receipt and verification of password and user name), provisions him with appropriate authorizations, and handles accounting for the time and services used by Joe on the data communications network. The AAA service uses a local database 22 to store and retrieve AAA information. To complete Joe's log-in, an access-accept packet is sent to NAS1 from AAA service 20. Then an IPCP (Internet Protocol Control Protocol) session is raised between NAS1 and Joe's terminal during which an IP address is returned to configure Joe's terminal's PPP stack. This completes the log-in of Joe.
Wholesale Providers also offer wholesale internet access to subsidiary and specialized service providers, CLECs (Competitive Local Exchange Carriers), corporations, and Community of Interest (COI) providers. Naturally, the processing afforded customers of the wholesale variety differs from the processing afforded customers of the retail variety. Subscriber information for individual wholesale users is usually stored by those who lease data communications network access from the ISP or Telco. Hence, corporations, CLECs and COI providers do not normally share their user information with the wholesale providers. The Wholesaler, however, typically also has its own retail subscribers whose user information is stored in its databases. In some cases, a particular user might have accounts with both a retail and a wholesale provider. Hence, the Wholesaler must distinguish between the user's wholesale and retail accounts and initiate different actions based upon their status or Service Level Agreements (SLAs).
Traditional wholesale ISPs and Roaming Service Providers offer network access through a technique called “authentication proxying.” Proxying involves the transfer of the authentication responsibility to the “owner” of the subscriber. Thus, if a corporation was to outsource its corporate intranet to a Wholesaler, it would give up the maintenance of its dial-up servers (i.e., the NASes). It would not, however, normally want to give up the control of or information regarding its employees. Hence, when a corporate user connects to such a Wholesaler's network access servers, the user essentially perceives that the user is dialing into a corporate facility when the user is actually dialing into the Wholesaler's domain and then somehow gaining admittance to the corporation's intranet.
What really happens in that scenario is that the Wholesaler determines that the user belongs to Corporation A (CorpA) by parsing either the fully qualified domain name (“FQDN”) (e.g., Joe@corpa.com) supplied by the user, reading the DNIS ID associated with the call, reading the CLID associated with the call, or by using some other known mechanism. Using a DNIS ID, the Wholesaler looks at the telephone number (or a specific NAS in access networks other than dial-up) through which the user is connecting to the network. So if a user calls in to 123-456-7890 from his number of 123-444-5555, then the Wholesaler can know which number was called, i.e., the completing station. Having determined that the user trying to gain access belongs to CorpA, the Wholesaler cannot authenticate the user by itself. As noted earlier, the user's record is still located on CorpA's equipment Hence, the Wholesaler will “proxy” out the authentication transaction from its AAA proxy service to CorpA. An AAA service within the corporation domain then identifies the user, verifies the password, and provisions the user with appropriate authorizations. It may also receive accounting information, if desired. Then the AAA service at CorpA notifies the Wholesaler's proxy service that the user is acceptable and passes along provisioning details associated with the user (such as an IP (Internet protocol) address to use or a pool identification of an IP address pool from which an IP address needs to be allocated and any other information that may be needed). The Wholesaler then grants the user access to the network based upon the reply it gets back from CorpA. This technique is called “proxying.” This is shown diagrammatically in FIG. 2.
To be able to perform basic proxying, the Wholesaler maintains minimal information on its proxy service 24 at its PoP. Information such as supported domain names, the IP address to which the transaction is to be sent, the port number (typically an OSI Layer 4 port number) to which the transaction is to be addressed, a shared secret between the proxy service and the remote AAA service, etc., are typically stored on proxy service 24's local configuration database 30.
For example, user Joe@corpa.com dials in to NAS1. A PPP (point to point protocol) session 26 is typically raised between Joe's terminal and NAS1 as is a LCP (Link Control Protocol) session. At this time the NAS1 generates an authentication request using a protocol such as RADIUS (Remote Authentication Dial-In User Service) to proxy service 24. Proxy service 24 then consults its local configuration database 30. Proxy service 24 then makes a determination about where to send the access-request packet Here it decides to send it to the AAA service 32 maintained in the CorpA domain 34. The CorpA AAA 32 then consults its local database 36 and authenticates Joe@corpa.com. CorpA AAA 32 then returns an access-accept packet to proxy service 24 which, in turn, sends an access-accept packet to NAS1. Then an IPCP (Internet Protocol Control Protocol) session is raised between NAS1 and Joe's terminal during which an IP address is returned to configure Joe's terminal's PPP stack thus completing the log-in of Joe@Corpa.com.
Frequently a large corporation or similar entity will have a need to provide PoPs at a number of locations to service its clients, customers and/or employees in a number of different cities. For example, a corporation “CorpA” located in Los Angeles, Calif. might have some employees using dial-up lines from San Francisco, Calif. and New York City, N.Y. Particularly in this situation, and in other situations, it is frequently desirable to establish a secure virtual private network (VPN) session which uses a tunneling protocol such as L2TP (layer two tunneling protocol) to effectively direct the communications from one node on the Internet to another node on the Internet Communications using these techniques are particularly secure because the entire packet is encapsulated by the protocol and within the encapsulation the data is encrypted. A particularly good way to establish the VPN session is between the NAS that the user is connected to and a gateway device at the location with which the user is to communicate. This might be, for example, a corporate intranet.
The overhead of a VPN session exceeds that of a normal session of a retail user logged in to a NAS because the NAS must handle the encryption duties and the additional overhead of the larger encapsulated packets. As a result, it would be desirable to provide a mechanism for accounting for such sessions, charging for them and limiting their use to a quantity contracted for. Doing so is, however, not particularly easy given the current limited accounting capabilities on the Internet.
For example, if CorpA has a great number of employees in San Francisco, they could overwhelm the PoP with VPN sessions back to the home office and possibly prevent regular retail or other wholesale customers of the Wholesaler from enjoying the quality and level of service that they have paid for. Similarly, a large number of employees using uncontrolled VPN sessions spread over many regions could potentially overwhelm the network maintained by the Wholesaler. Accordingly, the Wholesaler would like to enter into an arrangement with CorpA whereby CorpA pays a fee for a more or less specific maximum number of VPN sessions to occur at any one time. When CorpA exceeds this contracted number it is either cut off or charged an extra fee. In this way, the Wholesaler is able to plan for its expansion and receive realistic information on the number of these sessions that it must be able to support.